Automated Compliance Policy updates

Automate macOS Compliance Policies with Azure Automation

The manual grind

If you're managing macOS devices in Intune, you've probably been in this situation: Apple releases macOS 26.x, and you need to update your compliance policy to require 26.1 (or whatever version makes sense for your org). You open Intune, navigate to the compliance policy, update the minimum OS version, save, and you're done.

A week later, macOS 26.x+1 drops. Repeat the process.

This gets old fast. And let's be honest - we forget to do it sometimes. Or we're busy firefighting other issues and it sits on the backlog for weeks. Meanwhile, your devices are running on outdated OS versions that should be flagged as non-compliant.

There has to be a better way. And there is.

Enter automation

What if your compliance policies could update themselves? What if you could set a strategy like "always require the version that's 2 releases behind the latest" and let the system handle it?

That's exactly what we're building today. A PowerShell solution running in Azure Automation that:

And the best part? You can pin it to a specific major version. Testing a new version of macOS but want production on macOS 26? No problem. The script can track minor versions within 26.x and completely ignore the new major version you're testing until you're ready.

The strategy

Before we dive into the how, let's talk about version strategies. There are three approaches you can take:

Track major versions (conservative)
Stay 2-3 major versions behind. If the latest is macOS 26, require macOS 15 or 14. Good for organizations with older hardware that can't run the latest major version.

Track minor versions (aggressive)
Stay 1-2 minor versions behind within all major versions. If latest is 26.3, require 26.1. Good for modern fleets where all devices can run the latest major version.

Pin to major version (phased rollout) ← This is the sweet spot
Lock to a specific major version (like macOS 26) and track minor versions within it. If latest is 26.3, require 26.2, but completely ignore other major versions. Perfect for testing new major versions while keeping production stable.

Prerequisites

You'll need:

That's it. No servers to maintain, no infrastructure to manage. Azure Automation handles everything.

The setup

I'm not going to walk through every single click here (the full guide is on GitHub), but here's the overview:

1. Create Azure App Registration

Navigate to Azure AD → App registrations → New registration. Give it a name like "Intune-macOS-Compliance-Automation".

Under API permissions, add:

Create a client secret and save it somewhere secure. You'll need it in a minute.

2. Set up Azure Automation Account

Create an Automation Account. You can put it in whatever resource group makes sense for your org.

Under Variables (Shared Resources), create these:

Required:

Optional:

3. Upload the script

Create a new Runbook (PowerShell 7.2), paste in the script, save, and publish.

The script does all the heavy lifting:

  1. Fetches macOS versions from AppleDB API
  2. Filters to your pinned major version (if set)
  3. Sorts and finds the latest
  4. Goes back X versions (default 2)
  5. Authenticates to Microsoft Graph
  6. Reads your current compliance policy
  7. Updates it if needed

4. Schedule it

Link a schedule to the runbook. I run mine weekly on Tuesdays at 2 AM. Low-usage time, and if Apple drops a new version on Monday (they often do), it gets picked up Tuesday morning.

What it looks like in action

Here's the output from a successful run:

{
  "Success": true,
  "PolicyId": "36b9b86c-2297-4c2c-9b25-8c023f9d4d57",
  "PreviousVersion": "26.0.1",
  "NewVersion": "26.1.0",
  "Updated": true,
  "Duration": 15.49
}

The policy was at 26.0.1. The script calculated that 26.1.0 should be the minimum (1 minor versions below the latest 26.x). It updated the policy. Done in 15 seconds.

Next week, if Apple releases macOS 26.3, it'll bump to 26.2. Completely hands-off.

The pinning strategy in detail

Let me explain the pinning strategy since it's the most useful feature. This is an example and completely made up versions to get the thoughtprocess.

Without pinning:

Available versions:
- macOS 27.1 (latest)
- macOS 26.7
- macOS 25.9

With VersionsBelow = 2 (major versions):
Result: Requires macOS 25.9

With pinning to 26:

Available versions:
- macOS 27.1 (IGNORED)
- macOS 26.7 (latest in 26.x)
- macOS 26.6
- macOS 26.5
- macOS 25.9 (IGNORED)

With PIN_TO_MAJOR_VERSION = 26, VersionsBelow = 2:
Result: Requires macOS 26.5

This is perfect for phased rollouts. You're testing macOS 27 on 20% of your fleet, but production stays on 26.x. When you're ready to move everyone to 27, just change PIN_TO_MAJOR_VERSION to 27 and the script adapts.

Why AppleDB?

You might be wondering why we're using AppleDB instead of Apple's official APIs or Microsoft's data.

Simple: AppleDB is faster and more complete. When Apple drops a new macOS version, AppleDB has it within hours. Apple's official APIs can lag by days, and Microsoft's Intune data is even slower.

Plus, AppleDB has historical data going back years. If you need to check what versions are available for macOS 26, it's all there. The API is free, public, and reliable.

Troubleshooting

The most common issue during setup is permissions. Make sure:

The script includes built-in diagnostics. If something fails, check the job output in Azure Automation. It logs every step with timestamps.

I've also included a diagnostic runbook that tests each component separately:

  1. Variables load correctly
  2. Authentication works
  3. API permissions are granted
  4. Policy is accessible
  5. AppleDB is reachable

Run that first if you hit issues.

The maintenance burden

The beauty of this setup is there's almost nothing to maintain.

What you need to do:

What you don't need to do:

When you want to migrate from macOS 26 to 27, just change one variable (PIN_TO_MAJOR_VERSION = 27) and the script adapts.

Conclusion

Manual compliance policy updates are a thing of the past. This solution gives you:

The full script, detailed setup guide, and troubleshooting documentation is on GitHub (link below).

Set it up once, (almost) forget about it, and your compliance policies stay current automatically.

Have fun and good luck!

Resources